DAC Subdomains

Each branch or path within a Relationship structure can be used to implement a discreet set of Access Rules in a DAC Subdomain.  There must be at least one Subdomain in any DAC definition.

In the following example Project is the root of the Domain and two subdomains are configured under DAC access control – Subdomain_1 and Subdomain_2. Both subdomains control the Document ItemType in this case, but any relationship can be used.  Subdomain_1 has an intermediate Part node and enforces different access rules than Subdomain_2 for the same Document ItemType which is related directly to the Project. 

The Document under Part can gain an elevated access for Engineering Roles via DAC, whereas DAC can grant ‘Get’ access to all members of the Project Team to Documents related to the Project directly, depending on business requirements.

Figure 3.

DAC Subdomain Rules

For each subdomain used in a DAC Definition, the administrator must define one or more Subdomain Rules to ensure that the correct permissions are granted to the Leaf item. A subdomain rule determines the proper permissions to grant based on input of the fields shown in Figure 4 and described in Table 2.

Figure 4.

 

Table 1: Fields for granting permissions

Field	Description	Required?
Priority	Used to set the order in which the Rules are evaluated.  This is useful when the same Subdomain Permission and Root Permission pair appear in more than one row, but with a different (or blank) Life Cycle State (see detail below).	Yes
Subdomain Permission	Permission to grant to Leaf Item if Rule is satisfied.	Yes
Root Permission	Permission to match with the current permission on the Root Item (e.g. Project).	Yes
Destination Life Cycle State	If specified it forces a match with the current Leaf Item lifecycle state.	Optional

When the DAC Policy is active the fields are evaluated at runtime as shown in Figure 5.

Figure 5.

For example, consider subdomain rules described in Table 3.

Table 2: Subdomain rules

Subdomain Permission	Root Permission	Destination Life Cycle State
Preliminary_Document	Preliminary_Project
ReadOnly_Document	Released_Project	Released
DiscoverOnly_Document	Released_Project	Superseded

If these Rules were set on the Project->Document subdomain it would imply the following:

• If the Permission_ID on the Root (Project) is the ID of ‘Preliminary_Project’ then apply ‘Preliminary_Document’ permission to the Leaf (Document).

• If the Permission_ID on the Root (Project) is the ID of ‘Released_Project’ AND
  the LifeCycle State of the Leaf (Document) is ‘Released’ then apply ‘ReadOnly_Document’ permission to the Leaf (Document).

• If the Permission_ID on the Root (Project) is the ID of ‘Released_Project’ AND
  the LifeCycle State of the Leaf (Document) is ‘Superseded then apply ‘DiscoverOnly_Document’ permission to the Leaf (Document).

The Priority Field works as follows:

• No two rules may have the same Root Permission and LifeCycle State. This will issue a validation error when saving DAC Definition.

• If the Life Cycle State is left blank (implying ‘any’) then the Priority value must be a higher positive integer than any specified Life Cycle State.

Figure 6.

Example Scenario: Using a Subdomain Rule for Project Domain Access Control

The following is an example scenario of how a Subdomain Rule might be used:

• The Document Itemtype (outside of DAC) is configured with default “Discovery Only” access for All Employees. 

• Without DAC, MAC or Lifecycle driven permissions, this is the only access granted to employees.

• Non-employees would have no access.

• The Project Itemtype has a RelationshipType ‘Project Document’ with a related Document ItemType. 

• In DAC, a Query Definition is used to identify this relationship as a DAC Subdomain.

• The Access Policy has the following business requirements:

• All Project Team members receive “Get” access to Documents when added to the Domain and if the Root Permissions allow it. Access is then elevated for the Team.Users with the Administrator Role in the Project Team also getting “Can Change Access” rights in this case.

• A Rule is defined as follows:

  • Root Permission = ‘Released Project Permission.’

  • Destination Life Cycle State (blank).

  • Subdomain Permission = ‘Project Domain Member Access’:

    • Team Member: Get access.

    • Team Administrator: Get + Can Change Access.

• This Rule is added to the Subdomain and the DAC Policy is activated.

• A Document is added to the Project Relationship structure (Project Domain):

• Result: Team members can now open the form and view the Document.

• Team members with the Administrator Role also have ‘Can Change’ access.

Figure 7.

Subsequently rules can be added for different Root Permissions or LifeCycle States on the destination (Leaf) item, additional Team members, etc.

Mapping Team Roles from the Root Item Team

If there is a Team assigned to the Root item, and Roles are used in the Subdomain Permission (the permission that is assigned by the Rule calculation) then the Roles must match, otherwise there will not be a dynamic assignment by Role when the permission is applied.  See section “Creating Subdomain Permissions” for more information.